REMARKS 

The most recent office action has been carefully considered together with 
the present application and amendments have been made to several of the claims, most of 
which amendments are made to correct grammatical usages and improve consistency of 
terms. Applicants appreciate the examiner's recognition of allowable subject matter. 
Claims 28 and 30 have been amended to incorporate the subject matter of claim 1 and a 
small portion of claim 6 to make these independent claims. Claim 28 was indicated to 
contain allowable subject matter. While claim 30 was rejected, it is believed to contain 
allowable subject matter inasmuch as the subject matter of this claim was argued to be 
allowable and the examiner failed to address those arguments in the most recent office 
action. 

The examiner has maintained the rejections of claims 1-6, 10-27 and 47-52 
and 57-69 as being anticipated by Kardos et al. U.S. Patent No. 6,430,562 (hereinafter 
referred to as "Kardos") and has rejected the remaining claims (except those of which are 
now only objected to) under 35 U.S.C. § 103 over Kardos in view of Hull et al., U.S. 
Patent No. 6,487,457 (hereinafter referred to as "Hull"). 

The examiner has recognized allowable subject matter by only objecting to 
claims 28-29, 39-43 and 53-56 and indicates these claims would be allowable if rewritten 
in independent form. Claim 28 has been written in independent form as noted above. 
Apart from the examiner's response to applicants' Amendment A, the rejections that have 
been maintained with regard to the remaining claims are substantially similar to the 
original rejections, i.e., those contained in the office action dated October 1, 2003. 
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The examiner's response to the applicants' amendment states that Kardos 
clearly teaches integrated resource management system 10, which include the host 12 
which receive and/or generate work requests and scheduling requests that are transmitted 
in the form of messages to the message handler server 14 (Clearinghouse) for 
retransmission to the mobile work force management system 16. The message handler 
server 14 allows the plurality of host 12 to each communicate with the mobile work force 
management system 16 and thus forms an integrated system. The examiner also states 
that applicants in various sections of his argument alleged Kardos has no inspection 
capability nor is there selective authorization or operability that is a function of the log-in 
identity of clients. In response to that characterization of applicant's arguments, the 
examiner states "in response to applicants argument that the references fail to show 
certain features of applicant's invention, it is noted that the features upon which applicant 
relies, (i.e., inspection capability) are not recited in the rejected claim(s)." Applicants 
note that inspection capability is clearly recited in claim 6 in that claim 6 defines 
predefined events to include one or more events of a sizeable group. Inspection is 
certainly involved in certain identified events of the groups, namely, an inspection setup 
event, an inspection template setup event and an inspection processing event. These 
inspection events are further defined as well as claims 33, 34, 35, 36, 37, 38, all of which 
were rejected as being anticipated by Kardos. It is not understood how these claims do 
not relate to the inspection capability. They are certainly not limitations from the 
specification that are to be read into the claims. 
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In response to applicants' argument that the references fail to show their 
selective authorization or operability that is a function of the login identity of clients, the 
examiner asserted that "Kardos teaches assigning and generating or scheduling work 
orders according to the skill of the client. In other words, the OSS server 132 tracks on 
an aggregate level which technicians are scheduled to work which days as well as their 
skills in work areas. Based on this information and previously scheduled work, the OSS 
server 132 generates a schedule that provides time available on a per skill basis. The 
OSS server 132 is accessed by the host systems 12 and dispatch center 134 to schedule 
work as needed (see col. 16, lines 43-49). Also Kardos' system includes mechanism for 
identifying a login identity of the client or technicians and base of this information 
dispatched predetermined events or work orders to such clients (see col. 19, lines 53- 
62)". 

It is submitted that amended claim 1 is neither anticipated, taught nor 
suggested by Kardos. The system defined in amended claim 1 comprises at least one 
server adapted to receive predefined events from a client and forward said events to a 
clearinghouse via a communication link, and at least one client having a unique login 
identity and adapted to selectively send said predefined events to said server via said 
communication link. The final element of the claim states "a clearinghouse . . . being 
adapted to authorize selected predefined events by each client according to said login 
identity of such client . . It is clear that Kardos does not operate in this manner. It 
should be understood that a client is defined at page 3, line 12 as a computer which can 
be personal computers, other computers, mobile computing devices such as PDA's as 
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well as cell phone devices and that any of these devices would be referred to simply as a 
client. That being the case, the recitation that the client has a unique login identity is 
something quite different from what is being described at column 16, lines 43-49. That 
text states only that the OSS server 132 generates a schedule that provides time available 
on a per skill basis. Similarly, on column 29, at lines 43-55, it demonstrates that the OSS 
server 132 merely book work orders against resources on a requested day for individuals 
that have the "preferred skill set". An override indicator can prevent an appointment 
from being booked for people in such a preferred skilled set. This is again repeated at 
column 30, lines 34-45 where it is discussed that a booking request can be rejected 
because there are not enough resources to work the order on a requested day. More 
particularly, the discussion includes "this approach of first sending the request without 
override and then resending it with override in the event the first attempts fails may be 
necessary to overcome a limitation in the OSS server 132 which can prevent the 
appointment from being booked against the preferred skill set when the override indicator 
is set." It is clear that Kardos is intending to manage the technicians that are working for 
the company for the purpose of completing work orders. 

The examiner's reliance on column 19, lines 53-62 is also believed to be 
misplaced for the reason that all that is being accomplished as described is to send a 
message to an identified technician so that the identified technician can be dispatched to 
work on a work order. There is nothing in this portion of the specification to indicate that 
the technician is a client or that it has a unique login identity or that it is adapted to send 
anything, and particularly to selectively send said predefined events to said server via 
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said communication link. There is nothing in any of this cited text that indicates that a 
clearinghouse is adapted to authorize selected predefined events that can be performed by 
each client according to said login identity of each such client, to selectively schedule 
events in response to data stored in said database and to monitor the status of all said 
predefined events stored in said database. The Kardos system simply does not operate in 
this manner and therefore cannot anticipate the system as claimed, nor is it sufficiently 
close in its operation that it can teach or suggest the system as claimed. 

There is simply no teaching or suggestion in Kardos that only certain, i.e., 
selected predefined events that are determined according to the login identity of the client 
are available to be performed by the client. This discerning selectivity that originates 
with a client is simply not functionality that is carried out by Kardos, either singularly or 
in combination with Hull. 

The arguments that were made in the prior amendment with respect to the 
other claims were not addressed by the examiner in the office action to which this 
amendment responds and the examiner's comments regarding the rejections of them are 
essentially a repeat of the examiner's comments in the first office action. For 
completeness, applicants repeat those arguments here to make a complete record for 
appeal. 

Claim 4 further defines the system wherein one or more of said server, 
clearing house and client includes means for defining various levels of authorization for 
limiting access to predetermined events. Clearly, not only does Kardos not have the log- 
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in identity as defined in claim 1, but totally fails to anticipate, teach or suggest having 
various levels of authorization as is set forth in this claim. 

Claim 5 further defines the system wherein one or more of said server 
clearing house and client include predefined templates for selected events wherein said 
templates comprise a plurality of checklist items and possible responses to said checklist 
items. Nowhere in Kardos is there even a hint of the use of predefined templates for 
selected events wherein the templates comprise a plurality of checklist items and possible 
responses to those checklist items. Kardos simply is not designed to have this capability 
and therefore cannot anticipate, teach or suggest this claim. 

Claim 6 further defines applicants' system wherein said predefined events 
include one or more events selected from the group consisting of 19 separate events 
which relate to notification events, tasks events, set up events, work requests and request 
processing events, as well as work order and work order processing events. Assuming 
for the sake of argument that Kardos teaches or suggests any of these events, it cannot be 
honestly concluded that only a few of the events are comparable to those 19 events that 
are set forth in claim 6. Kardos is not designed to operate in the manner described in this 
claim and certainly cannot anticipate, teach or suggest a system having this functional 
capability. 

With regard to claim 7, it further defines a system as creating a notification 
event responsive to preselected ones of said predetermined events not having been 
completed as prescribed and are therefore overdue. The examiner admits that Kardos is 
silent regarding the functionality of this claim and cites Hull as supplying the deficiency 
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in an obviousness rejection. However, Hull fails to teach or suggest the subject matter of 
this claim because there is no notification event produced by Hull responsive to the event 
being overdue. The citation to column 12, line 65 to columns 13, line 10 which the 
examiner apparently relies on is totally misplaced. Hull merely contacts a designated 
person if the system cannot find utility rates in the context of a building management 
system. Additionally, Hull does not create a notification event responsive to preselected 
ones of said predetermined events not having been completed. 

With respect to claim 11, it claims a system wherein during preselected 
ones of said events an authorized client is adapted to add new data, edit existing data or 
exit said event. Kardos fails to anticipate, teach or suggest this claim because it simply 
does not operate in the manner whereby an authorized client can add new data, edit 
existing data or exit the event. Claim 12 should be allowable for similar reasons. 

With respect to claim 13, it further defines the system wherein said 
clearinghouse selectively provides authorization to said client to request events in 
response to said client communicating its unique log-in identity to the server. Since the 
Kardos system is not concerned with authorization or unique log-in identities, it is 
incapable of anticipating, teaching or suggesting the subject matter of this claim. 

Claim 14 is similarly incapable of being anticipated, taught or suggested by 
Kardos for the reason that it does not have a download tasks event that can be requested 
after authorized communication is established. Moreover, claim 15 further defines 
additional functionality when during said download tasks event the authorized client 
downloads task list data from the clearinghouse and determines whether the data is valid 
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and also determines whether communication with said server is disconnected when the 
task list data is not valid. Kardos simply is incapable of anticipating, teaching or 
suggesting the subject matter of this claim because Kardos simply does not operate in this 
manner. 

Claim 16 adds further functionality wherein during one of a download tasks 
event or an upload task event, said authorized client is adapted to make an entry into in an 
exception log when communication with said one server is disconnected. Kardos does 
not operate in this manner and the notion of an exception log is not mentioned anywhere 
in the Kardos patent. 

Claim 17 further defines the system of claim 16 wherein during one of said 
downloads tasks event or said upload task event, said authorized client is adapted to 
check communication for a predetermined maximum retry count when communication 
with the server is disconnected and make an entry an exception log once the 
predetermined maximum retry count has been tried. Kardos does not operate in this 
manner and is therefore incapable of anticipating, teaching or suggesting the subject 
matter of this claim. Claims 18 and 19 define additional functionality during the 
download tasks event that is incapable of being performed by Kardos and is not 
anticipated, taught or suggested by Kardos. 

Claim 23 further defines the system wherein during said performed task 
event said clearinghouse is adapted to forward checklist item data for said task to said 
server. Claim 24 further defines the system wherein during said performed task event 
said server is adapted to send said checklist item data to said authorized client and claim 
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25 further defines a system wherein during said performed task event, said authorized 
client is adapted to display a list of the checklist items from the checklist item data for 
completing said checklist items. Kardos simply does not operate in this manner because 
it does not utilize checklists in the manner as claimed. Further, claim 26 defines a system 
wherein during said performed task event, said authorized client is adapted to respond, 
skip or stop said checklist item from said checklist item data until all checklist items have 
been completed. This claim is not anticipated, taught or suggested by Kardos because it 
does not operate in a manner which utilizes checklists and certainly does not facilitate the 
functionality whereby the authorized client can respond, skip or stop each checklist item 
from the data as claimed. 

Claim 27 further defines the system wherein during said performed task 
event, said authorized client is adapted to exit the display as claimed, store response data 
for said checklist item when the client elects to respond to the same and respond, skip or 
stop the next item from the checklist item data when said authorized client elects to skip 
said first checklist item. Clearly Kardos does not utilize checklist items in the manner as 
set forth in this claim and therefore cannot anticipate, teach or suggest it. 

Claim 30 further defines a system wherein performance rating type set-up 
event allows said authorized server to display an option menu for yes/no type, multiple 
options type and numerical type performance rating to said authorized client for 
selection. There is no inspection carried out by either Kardos or Hull and therefore this 
claim cannot be taught or suggested by either Hull or Kardos. Moreover, since they do 
not do inspections and are not concerned with any performance rating, they clearly do not 
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have the capability of displaying an option menu for the various types of performance 
rating that are set forth in this claim. 

Since they do not perform the performance rating type set-up event, neither 
of these references can teach or suggest the subject matter of claim 31 which saves the 
performance rating type data onto said database. Further, claim 32 cannot be taught or 
suggested by Hull or Kardos for the reason that they simply do not define tolerance levels 
to create a special action event for performance rating data stored in the database. Kardos 
and Hull cannot teach or suggest this claim because neither is designed to carry out 
inspections at all, much less carrying out a performance rating or define a tolerance level 
to create a special action event based on performance rating type data. 

Claim 33 is not taught or suggested for the simple reason that neither 
Kardos nor Hull teach or suggest inspection functionality and particularly the 
functionality of an authorized client inputting and editing inspection templates data for a 
specific jobsite. They simply do not have this functionality. Similarly, claim 34 cannot 
be taught or suggested by Kardos or Hull because they are not concerned with inspection 
templates data, much less inspection steps that are carried out according to a default 
checklist item data or a user defined checklist item data stored in said database. The 
words "inspect" or "inspection" do not appear anywhere in either the Kardos or Hull 
patents. 

Claim 35 further defines the system wherein said clearinghouse is adapted 
to respond to inspection data sent from an authorized client during an inspection 
processing event and determine whether the inspection data from said authorized client 
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are valid. Not only are Kardos and Hull not concerned with inspection capability, neither 
patent discusses determining whether received inspection data is valid. The only 
checking that appears to be done by Kardos is to determine whether messages were 
received, which is completely different from what is claimed. 

Claim 36 further defines the system wherein during said inspection 
processing event the clearinghouse is adapted to make an entry in an exception log when 
said inspection data is not valid and is not taught or suggested by Hull or Kardos, applied 
singularly or in combination for the same reasons set forth with regard to claim 35. 
Claims 37, 38 and 39 are not taught or suggested by Kardos or Hull, applied singularly or 
in combination for the same reasons that were set forth with regard to claims 30, 31 and 
32 relating to tolerance levels. 

Claim 46 further defines the system wherein during said work request 
processing event, said authorized client is adapted to enter an approval code when said 
authorized client accepts a selected open work request from said list. The notion of a 
client entering an approval code when said authorized client accepts a selected open work 
request is simply not a capability that is discussed, inferred or suggested by Kardos. 
Approval in this context or any context is not even mentioned in the Kardos patent. For 
similar reasons, claims 47 and 48 are not anticipated, taught or suggested by Kardos. 

With regard to claim 49, it defines a system wherein during said work 
request processing event, said authorized client is adapted to enter an explanation for said 
selected work request data when said authorized client rejects a selected open work 
request data stored in said database. Kardos does not teach or suggest the functionality of 
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the authorized client rejecting a selected open work request data. Any rejection of a work 
request in Kardos is done at the server level, i.e., there aren't enough resources in the 
workforce to carry out some requested work. This is a very different functionality. The 
notion of a client rejecting a work request is simply not contemplated or discussed in 
Kardos. 

Claim 68 is directed to a method for managing operational facilities using 
predefined events to carry out managing operations for the facilities as claimed and 
includes the step of selectively authorizing, by the clearinghouse, said events from each 
client according to said log-in identity of each such client among the other steps as set 
forth in the claim. Because Kardos does not selectively authorize events according to the 
log-in identity of each client, it certainly fails to anticipate, teach or suggest this claim. 
The arguments that are set forth with regard to claim 1 above also apply here. Claim 70 
is also believed to be allowable for the same reasons that were advanced with regard to 
claim 1 . 

With regard to the dependent claims that were not specifically discussed 
herein, these claims depend from one or more other claims and necessarily include the 
subject matter of those one or more claims in addition to reciting further structure and/or 
functionality not found in those claims. Because of these reasons, it is also believed that 
these dependent claims are allowable. 
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For these reasons, applicants respectfully request reconsideration and 
allowance of all claims presenting pending in the application. 

Respectfully submitted, 

GREER, BURNS & CRAIN, LTD. 

Roger D. Greer 
Registration No. 26,174 

May 26, 2004 

300 South Wacker Drive, Suite 2500 
Chicago, Illinois 60606 
(312) 360-0080 
Customer No. 24978 
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